1. Field of the Invention
This invention relates generally to the field of data object creation and manipulation, and more particularly, to object creation and manipulation in both distributed and non-distributed environments.
2. Description of the Related Art
Integrated development environments (“IDEs”) are used for the development of software. A typical IDE consists of a user interface, a repository of information, and tools. The function of the user interface is to provide a user-friendly means of viewing, and performing actions on, the information in the repository in an integrated way. The purpose of the repository is to maintain information, both at run time and persistently.
The tools are used to populate the repository. They perform operations on the information contained in the repository, and are also driven by that information, so that the results of the operations performed by the tools depend on what information is contained in the repository. Examples of tools often found in IDEs include parsers, code generators, linkers, search tools and file system management tools.
In such a typical IDE, the tools and repository are configured so as to be able to communicate with one another, in order to allow the tools to perform operations on the information in the repository, and to receive information from the repository to allow the tools to perform the required operations. The user interface is configured so as to communicate directly with the repository, in order to allow it to display, in a user-friendly manner, the information contained in the repository. The user interface communicates directly with the repository in order to provide the user with access to the information therein. The user interface also communicates with the tools in order to provide the user with a means of applying the tools to the information within the repository as the user desires.
Thus, this typical architecture provides a close integration among the user interface, repository and tools. This close integration has its benefits. Specifically, the close integration provides the user with a rich and more complete pool of information within the repository. Also, there is a comprehensive interface from the user interface into the tools.
Furthermore, in a typical IDE, at least the tools and the repository are written in the same language. This is done to provide a performance benefit in the form of higher speed and more comprehensive functionality. Furthermore, the repository and/or the tools are also typically written in platform-specific languages. This is also intended to increase performance, provide greater speed, and allow for the closer integration of the tools with the repository.
However, this architecture presents a number of problems. The first, is that the close integration between the user interface, tools and repository creates interdependencies between those components. Specifically, the close integration of the user interface, repository and tools means that each of these components is built around the specific features of the other components. The result is that if it is desired to change or substitute any one of these components, then it may be necessary to change or substitute the remainder of the components. Another related result is that porting any part of the system to another platform is very difficult, because when one of the components is changed to accommodate its new platform, the other components will need to be changed as well.
Second, the above-described architecture is poorly suited to a distributed, heterogenous development environment in which different components are housed on different platforms. As stated above, the components are often written in platform-specific languages. Thus, in a tightly coupled system, components on different platforms will be unable to communicate with one another unless additional software is added to facilitate such communication. However, this additional software layer is likely to compromise the performance of the system, precisely because it would have the effect of loosening the coupling between the components and preventing them from communicating with one another in a direct manner.
It will be appreciated that, because of the tight coupling of the components of the typical IDE, it is likely to be relatively inflexible. This is because, as stated above, for reasons of performance the components are designed and written with the specific existing features of the other components in mind. In other words, each component expects the other components to have the specific features that those other components have. Therefore, this tight coupling often makes it difficult to add additional features to an existing IDE. In particular, it may be difficult to extend tool functionality within a typical IDE, because the repository and user interface were not designed with that additional functionality in mind. Thus, additional functionality would require significant changes to the other components as well.
It will also be appreciated that these problems are not unique to IDEs. Many computer systems have a general architecture consisting of a user interface, a data repository and tools. Examples include word processors and chatroom systems, to name but two. The above-described difficulties can also arise in these other systems.
U.S. Pat. No. 6,134,581 discloses a method and system for remotely browsing objects. The system includes a management framework for a network management system. Various management services can be loaded or plugged into the framework dynamically. To add a new management service, an adaptor is needed to mediate between the framework and the management service being added. The new service is then plugged into the adaptor.
While this system allows for the addition of new services, it requires an additional adaptor for each new service. The presence of this intervening software layer may have a negative impact on performance. Furthermore, the necessity of creating such adaptors adds cost to the system. Finally, this system is specifically designed for network management; it does not provide for the common scenario in which the user interface through which the objects are browsed is on the same platform as the objects themselves.
U.S. Pat. No. 5,950,000 discloses a method and system for integrating third party tools into an integrated programming environment which supports control and data integration. In this system, the graphical user interface of the system manager is augmented with an icon representing a selected third party tool. The user interface also provides menus which are controlled to show objects and files that have been used recently, and through which tools they have been used. The tools and the system manager communicate through inter-process messaging to provide the information for display in the menus on the graphical user interface. Also, in this system, in order to integrate third party tools more closely with the system manager, the provider of a third party tool is provided with the option of writing “glue code” to ensure sufficient integration.
There are a number of problems inherent in this design. First, with respect to at least some tools, “glue code” is required to properly integrate the tool and the manager. The production of this code adds to the cost of the overall system. Second, the mode of communication between the third party tools and the system manager, namely, inter-process messaging, creates an extra layer of communication between the objects upon which the tools operate and the tools themselves. This can have a negative effect on performance of the system.